home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group98a.txt / 000071_icon-group-sender _Fri Feb 27 17:03:48 1998.msg < prev    next >
Internet Message Format  |  2000-09-20  |  3KB
  1. Return-Path: <icon-group-sender>
  2. Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
  3.     by baskerville.CS.Arizona.EDU (8.8.7/8.8.7) with SMTP id RAA01284
  4.     for <icon-group-addresses@baskerville.CS.Arizona.EDU>; Fri, 27 Feb 1998 17:03:47 -0700 (MST)
  5. Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
  6.     id AA01261; Fri, 27 Feb 1998 17:03:46 -0700
  7. Date: Fri, 27 Feb 1998 23:39:29 +0300 (MEST)
  8. From: Ehud Lamm <mslamm@mscc.huji.ac.il>
  9. To: gep2@computek.net
  10. Cc: icon-group@optima.CS.Arizona.EDU
  11. Subject: Re: icon questions
  12. In-Reply-To: <199802271848.MAA12819@axp.cmpu.net>
  13. Message-Id: <Pine.A32.3.91.980227233411.26902B-100000@pluto.mscc.huji.ac.il>
  14. Mime-Version: 1.0
  15. Content-Type: TEXT/PLAIN; charset=US-ASCII
  16. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  17. Status: RO
  18. Content-Length: 1647
  19.  
  20. On Fri, 27 Feb 1998 gep2@computek.net wrote:
  21.  
  22. > While for certain types of compute-intensive applications large amounts of data 
  23. > conversions might be an issue, much of the time nowadays (and for large classes 
  24. > of applications areas) these minor conversions are simply unimportant from an 
  25. > overall perspective.
  26. > 
  27. > In the time it might take a programmer to conceive and implement a solution 
  28. > minimizing or eliminating one conversion, the CPU to be used could probably 
  29. > perform millions of such conversions.  And the CPU costs a *great* deal less per 
  30. > hour than most (especially, good) programmers do!!  :-)
  31. > 
  32.  
  33. As one who manages programmers, I heartly agree that programmer time is 
  34. what really costs you. Not only are programmers expensive, it so happens 
  35. that if they are wasted doing something useless, they are not programming 
  36. the next project you have for them.
  37.  
  38. However, this is no reason to produce sloppy code... In the majority of 
  39. the cases I see of sloppy/slow/unelegant code, the reason isn't that the 
  40. solution was really cheaper in man-hours. It means simply that the man is 
  41. not a great programmer.
  42.  
  43. In some cases (for example onetime scripts, higly clever algorithms etc.) 
  44. dealling with all the low level stuff (such as type conversions) is a 
  45. waste of time. 
  46.  
  47. But even in such cases, the compiler should be able to optimize most of 
  48. the trivial performence problems. Unnneded (obvious) conversions are an 
  49. example. 
  50.  
  51. The sad thing about optimization, is that it is never a replacement for a 
  52. good programmer, and a good algotrithm. 
  53.  
  54. These are still what really count.
  55.  
  56. Ehud Lamm     mslamm@pluto.mscc.huji.ac.il
  57.  
  58.